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General Description 

This Chapter describes the required capabilities at the MS, the PDSN, the HA and the RADIUS 
servers to provide Simple IPv4, Simple IPv6 and Mobile IPv4 access services over PPP. It 
describes the mechanisms of updating the DNS with the user's assigned IP address as described 
in the IP Reachability Service capability. 
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1 1 Glossary and Definitions 

2 SeeX.S0011-001-C. 
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1 2 References 

2 SeeX.S0011-001-C. 

3 



2 



X.S0011-002-Cv1.0 



1 3 Simple IP Operation 

2 This section describes the requirements and procedures for Simple IP operation for both IPv4 

3 [RFC 791] and IPv6 [RFC 2460]. In this specification, Simple IP refers to a service in which an 

4 MS is assigned an IP address and is provided IP routing service by an access provider network. 

5 The MS retains its IP address as long as a radio network that has connectivity to the same 

6 Serving PDSN serves it. IP address mobility beyond the Serving PDSN and secure access to a 

7 home network are beyond the scope of this specification. 

8 3.1 Common Service Specification 

9 The common requirements for several network elements (e.g., PDSN and MS) for Simple IP 

10 operation are described here. 

11 3.1.1 PPP Session 

12 PPP shall be the data link protocol between the MS and the PDSN. The PPP session shall be 

13 established prior to any IP datagram being exchanged between the MS and the PDSN. Only one 

14 PPP session shall be supported between the MS and the PDSN. 

15 PPP shall be supported as defined in the following standards with any limitations or extensions 

16 described in this specification. 

17 • Point to Point Protocol [RFC 1661]; 

18 • PPP in HDLC-like Framing [RFC 1662]; 

19 • IPCP [RFC 1332] (for IPv4); 

20 • IPv6CP [RFC 2472] (for IPv6); 

21 • CHAP [RFC 1994]; 

22 • PAP [RFC 1334]. 



23 PPP encryption is not supported in this specification. 

24 3.2 PDSN Requirements 

25 The PDSN shall support Simple IP operation for both IPv4 and IPv6. 

26 3.2.1 PPP Session 

27 3.2.1.1 Establishment 

28 If the PDSN supports multiple service instances, refer to X.S001 1-004-C for details of PPP 

29 negotiation, otherwise, when an R-P connection of SO type 33/59 is established it shall send an 

30 LCP Configure-Request for a new PPP session to the MS. 

31 PPP shall support transparency in accordance with Section 4.2 of RFC 1662. The PDSN shall 

32 attempt to negotiate a control character mapping with the minimum number of escaped 

33 characters by proposing an ACCM of 0x00000000. 

34 3.2.1.2 Termination 

35 The PDSN shall close the PPP session if there is no established R-P or P-P session for the MS. 

36 If the PPP session timer is used and has expired, or if Always On service is not enabled and the 

37 PPP inactivity timer for a PPP session expires, the PDSN shall close the PPP session. The 

38 PDSN may receive the Always On attribute with value '1 ' from the Home RADIUS server in order 

39 to activate the Always On service for a user. If the PDSN receives the Always On attribute with 

40 value '1', it shall send the indicator to the RN as indicated in [4]. 
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1 Upon receiving the Always On attribute with value '1' from the Home RADIUS server the PDSN 

2 shall utilize the expiration of the PPP inactivity timer and the procedures described in Section 

3 3.2.1.7 to determine if the PPP session should be closed. 

4 When the PDSN determines that the PPP session shall be closed, it shall determine if an LCP 

5 Terminate-Request should be sent to the MS. For an Always On session, the PDSN shall send 

6 an LCP Terminate-Request to the MS. The PDSN should also send LCP Terminate-Request to a 

7 non-Always On session unless it has previously received the 'All Dormant Indicator' NVSE. 

8 The PDSN shall clear the R-P and/or P-P session whenever the associated PPP session is 

9 closed. If the PDSN receives IP packet(s) for an MS for which there is no established PPP 

10 session, the PDSN shall silently discard the packet(s). The PDSN shall close the R-P and 

1 1 associated P-P session if it receives an LCP Terminate-Request message from the MS. 

12 3.2.1.3 PPP Session Authentication 

13 The PDSN shall support the two authentication mechanisms: CHAP and PAP. The PDSN shall 

14 also support a configuration option to allow an MS to receive Simple IP service without CHAP or 

15 PAP. The PDSN shall propose CHAP in an initial LCP Configure-Request message that the 

16 PDSN sends to the MS during the PPP establishment. If the PDSN receives an LCP Configure- 

17 NAKfrom the MS containing PAP, the PDSN shall accept PAP by sending an LCP Configure- 

18 Request message with PAP. If the PDSN receives an LCP Configure-Reject containing the 

19 Authentication-Protocol option and the PDSN is configured to allow the MS to receive Simple IP 

20 service without CHAP or PAP, the PDSN shall respond with an LCP Configure-Request without 

21 the Authentication-Protocol option and shall adhere to the guidelines in Section 3.2.2.1 for NAI 

22 construction for accounting purposes. 

23 3.2.1.4 Addressing with IPCP 

24 3.2.1.4.1 IPv4 Addressing 

25 For IPv4, the PDSN shall assign the MS an IP address for Simple IP service when presented with 

26 a zero or non-zero IP address in the IP Address Configuration option, during the IPCP phase of 

27 PPP. The IP address may be a private address as per RFC 1918. If the MS requests a non-zero 

28 IP address during the IPCP phase, the PDSN shall send an IPCP Configure-Nak in response to 

29 the request in order to propose a different IP address. If the MS responds with an IPCP 

30 Configure-Request containing an IP address different from the one proposed by the PDSN, the 

31 PDSN shall re-transmit one time the IPCP Configure-Request containing the new IP address, 

32 and shall send an LCP Terminate- Request if the MS fails to accept the assigned IP address. 

33 During IPCP phase, the PDSN shall include the IP Address Configuration option containing its IP 

34 address in the IPCP Configure-Request messages sent to the MS. 

35 The PDSN shall implement IPCP configuration options as defined in RFC 1877 for the DNS 

36 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP 

37 addresses with the MS if the DNS Server Configuration options are received during the IPCP 

38 phase. 

39 3.2.1.4.2 IPv6 Addressing 

40 For an IPv6 MS, the PDSN shall be the default router and the PPP termination point. The PDSN 

41 shall allocate one globally unique /64 prefix to each PPP link. The PDSN shall not construct any 

42 global address from this prefix. 

43 The PDSN shall support the following RFCs, with exceptions as noted in this specification: 

44 • An IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; 

45 • Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; 

46 • Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; 
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• IPv6 Stateless Address Autoconfiguration [RFC 2462]; 

• Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 



4 



(IPv6) Specification [RFC 2463]; 
• IP Version 6 over PPP [RFC 2472]; 
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IP Version 6 Addressing Architecture [RFC 3513]. 



6 The PDSN shall perform Interface-identifier negotiation as described in RFC 2472. The PDSN 

7 shall provide a valid non-zero Interface- Identifier during its negotiation of the Interface-identifier. 

8 The PDSN shall not have more than one Interface Identifier associated with the PPP connection, 

9 i.e., the PDSN shall only use the Interface Identifier negotiated during the IPv6CP phase with the 

10 MS. Because the Interface-Identifier is negotiated in the IPv6CP phase of the PPP connection 

1 1 setup, it is not required to perform duplicate address detection for the link local address forms as 

12 part of IPv6 stateless address auto-configuration [RFC 2462]. 

13 Following successful IPv6CP negotiation and the establishment of a unique link-local address for 

14 both the PDSN and the MS, the PDSN shall immediately 1 transmit initial unsolicited Router 

15 Advertisement (RA) messages on the PPP link using its link-local address as a source address. 

1 6 The PDSN shall include a globally unique /64 prefix in the Router Advertisement message to the 

17 MS. The MS shall use this prefix to configure its global IPv6 addresses. 

18 The PDSN shall send unsolicited Router Advertisement (RA) message for an operator 

19 configurable number of times. Also, the PDSN shall set the interval between initial RA messages 

20 to an operator configurable value, which may be less than 

21 MAX_INITIAL_RTR_ADVERT_INTERVAL. After the configurable number of initial unsolicited RA 

22 messages has been transmitted, the interval between the periodic transmissions of unsolicited 

23 RA messages shall be controlled by the router configurable parameters MaxRtrAdvlnterval and 

24 MinRtrAdvlnterval as defined in RFC 2461 . The PDSN may set MaxRtrAdvlnterval to a value 

25 greater 2 than 1 800seconds and less than 1/3 of the AdvDefaultLifetime. The PDSN shall set 

26 MinRtrAdvlnterval 2 to a fraction of MaxRtrAdvlnterval as per RFC 2461 . 

27 The PDSN shall send a RA message in response to a Router Solicitation (RS) message received 

28 from the MS. The PDSN may set the delay between consecutive (solicited RA) or (solicited 

29 /unsolicited RA) messages sent to the all-nodes multicast address to a value less 3 than that 

30 specified by the constant MIN_DELAY_BETWEEN_RAS, contrary to the specification in sec. 

31 6.2.6 of RFC 2461. 

32 The advertised /64 prefix 4 identifies the subnet associated with the PPP link. The /64 prefix 

33 advertised by the PDSN shall be exclusive to the PPP session. 

34 The PDSN shall set 

35 • the M-f lag = 0 and the O-f lag = 0 in the RA message header; 

36 • the L-flag = 0 and the A-flag =1 in the RA message Prefix Information Option. 

37 The PDSN shall set the Router Lifetime value in the Router Advertisement message to a value of 

38 2 16 -1 (18.2 hrs). 



1 This is an exception to RFC 2461 necessary to optimize applicability over the cdma2000 
wireless air-interface. 

2 This may cause an exception to RFC 2461 as it may put the interval outside the normal range. 
This exception is allowed by this standard to optimize IPv6 RA over the cdma2000 wireless links. 

3 This exception is allowed by this standard to optimize IPv6 RA over the cdma2000 wireless 
links. 

4 If the Access Service Provider desires to reduce frequent unsolicited RA for the prefix, it should 
set the 32-bit Valid Lifetime and Preferred Lifetime fields for the advertised /64 prefix in the RA 
message Prefix Information Option to a very high value (i.e., OxFFFFFFFF to indicate prefix 
validity for the lifetime of the PPP session). 
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1 The PDSN shall not send any redirect messages to the MS over the PPP interface. 

2 3.2.1.5 Compression 

3 The PDSN shall support the following header compression algorithms: 

4 • Van Jacobson TCP/IP header compression [RFC 1 144]. 

5 The PDSN may support the following header compression algorithms: 

6 • ROHC, Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 

7 3095] with ROHC over PPP [RFC 3241]; 

8 • ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC3242]; 

9 • IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC 

10 2509]; 

1 1 • Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer 

12 Assisted RObust Header Compression (ROHC) Profile [RFC3408]; 

13 • Compressing IP/UDP/RTP headers on links with high delay, packet loss and 

14 reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544]. 

15 If the PDSN is able to process received compressed header packets from the MS using various 

16 header compression protocols, the PDSN shall include the appropriate configuration option(s) to 

17 the MS to indicate which IP Header Compression protocol it supports in the IPCP or IPv6CP 

18 Configure-Request message as defined by RFC 1332, RFC 3241, RFC 2509, and RFC 3544. 

19 The PDSN shall support CCP [RFC 1962] for the negotiation of PPP payload compression. The 

20 PDSN shall support 5 the following algorithms of PPP payload compression: 

21 • Stac-LZS [RFC 1974]; 

22 • Microsoft Point-To-Point Compression Protocol [RFC 2118]; 



23 The PDSN may support other PPP payload compression algorithms. 

24 3.2.1.6 PPP Framing 

25 The PDSN shall frame PPP packets sent on the PPP link layer using the octet synchronous 

26 framing protocol defined in RFC 1662, except that there shall be no inter-frame time fill (see 4.4.1 

27 of RFC 1662). That is, no flag octets shall be sent between a flag octet that ends one PPP frame 

28 and the flag octet that begins the subsequent PPP frame. 

29 For IPv6, the PDSN shall set the MTU size as specified in RFC 2460. 

30 3.2.1.7 PPP Link Status Determination 

31 For Always On users, the PDSN shall support the 3GPP2 vendor specific Max PPP Inactivity 

32 Timer packet defined in PPP Vendor specific packet [RFC 2153] and the following configurable 

33 timer and counter: 

34 • Echo-Reply-Timeout timer. 

35 • Echo-Request-Retries counter. 

36 The format of the Max PPP Inactivity Timer packet is shown in Figure 1 



5 The PDSN shall not send compressed PPP frames when Multiple Service Instances are 
connected. 
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Code 


Identifier 


Length 


Magic Number 


OUI 


Kind 


Max PPP Inactivity Timer 



2 Figure 1 - Max PPP Inactivity Timer Packet 

3 

Code = 0 (As defined in RFC 21 53) 

Identifier = The Identifier field shall be changed for each Vendor Specific 

packet sent 

Length = 16( octets) 

Magic Number = The Magic-Number field is four octets and aids in detecting links 

that are in the looped-back condition. Until the Magic-Number 
Configuration Option has been successfully negotiated, the Magic- 
Number shall be transmitted as zero. See the Magic-Number 
Configuration Option for further explanation. 

OUI = 0xCF0002 

Kind = 1 

Max PPP Inactivity Timer = 32-bit value = PPP inactivity time + Echo_Reply_Timeout timer 
x(Echo_Request_Retries + 1) 

4 Upon entering the IPCP Opened state on a PPP session configured for Always On Service, the 

5 PDSN shall start the PPP inactivity timer for the PPP session, and shall send the 3GPP2 vendor 

6 specific Max PPP Inactivity Timer packet [RFC 2153] over the main service instance. The PDSN 

7 should resend the Max PPP Inactivity Timer packet a configurable number of times if no 

8 response from the MS is received. The value in the Max PPP Inactivity Timer field shall be equal 

9 to [PPP inactivity timer + Echo_Reply_Timeout timer * (Echo_Request_Retries + 1 )] for the PPP 

10 session. The PDSN shall reset the PPP inactivity timer upon detection of traffic activity. 

1 1 If the PPP inactivity timer value, Echo-Reply-Timeout timer and/or Echo-Request-Retries counter 

12 have changed by an administrative action, the PDSN shall send the 3GPP2 vendor specific Max 

13 PPP Inactivity Timer packet over the main service instance. 

14 Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo-Request message 

15 [RFC 1661] over the main service instance, and start the Echo-Reply-Timeout timer for the PPP 

16 session. It shall also initialize the Echo-Request-Retries counter to a configurable integer value. 
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1 Upon receipt of an LCP Echo-Reply message, an LCP Code-Reject [RFC 1661], or any other 

2 PPP packet for the PPP session, the PDSN shall stop and reset the Echo-Reply-Timeout timer, 

3 reset the Echo-Request-Retries counter, and reset the PPP inactivity timer. 

4 Upon expiration of the Echo-Reply-Timeout timer and when the Echo-Request-Retries counter 

5 value is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the 

6 Echo-Request-Retries counter by one, and start the Echo-Reply-Timeout timer. Upon expiration 

7 of the Echo-Reply-Timeout timer and when the Echo-Request-Retries counter value is equal to 

8 zero, the PDSN shall close the PPP session. In this case, the PDSN shall not send an LCP 

9 Terminate-Request to the MS. 



10 3.2.2 RADIUS Support 



15 
16 
17 
18 
19 
20 



The PDSN shall act as a RADIUS client in accordance with RFC 2865 and shall communicate 
CHAP or PAP authentication information to the Visited RADIUS server in a RADIUS Access- 
Request message. Upon receipt of the CHAP or PAP response from the MS, the PDSN shall 



Attribute Name 


Type 


Access- 


Access- 


Interface(s) 






Request 


Accept 




User-Name 


1 


M 


M 


PDSN <-> AAA 


User-Password 


2 


0 Note 1 




PDSN -> AAA 


CHAP-Password 


3 


0 Note 2 




PDSN -> AAA 


NAS-IP-Address 


4 


0 Note 3 




PDSN -> AAA 


NAS-IPv6-Address 


95 


0 Note 3 




PDSN -> AAA 


CHAP-Challenge 


60 


0 




PDSN -> AAA 


Correlation ID 


26/44 


M 


0 


PDSN <-> AAA 


Callinq-Station-ID 


31 


0 




PDSN -> AAA 


Always On 


26/78 




0 


PDSN <- AAA 


NAS-Port-Type° 


61 


0 




PDSN -> AAA 



(M) Indicates Mandatory Attribute 

(O) Indicates Optional Attribute 
Note 1: User-Password is mandatory if PAP. 
Note 2: CHAP-Password is mandatory if CHAP. 

Note 3: At least one of NAS-IP-Address or NAS-IPv6-Address shall be included. 

Table 1 - Occurrence of RADIUS Attributes for Simple IP 



21 Additional RADIUS attributes and VSAs may be returned in the RADIUS Access-Request and 

22 RADIUS Access-Accept messages as per X.S001 1-005-C. 

23 The Correlation ID is in addition to those fields specified by RFC 2865 and RFC 3162. 

24 The PDSN shall also act as a RADIUS accounting client in accordance with RFC 2866 and shall 

25 communicate user accounting information to the Visited RADIUS server in RADIUS Accounting- 

26 Request (Start and Stop) records. The RADIUS Accounting-Request message shall contain the 

27 accounting attributes as specified in X.S001 1-005-C. The PDSN may also send RADIUS 

28 Accounting-Request (Interim-Update) records between the Accounting-Request Start and Stop 

29 messages as necessary in accordance with Annex A of X.S001 1-005-C. 

30 The security of communications between the PDSN and the RADIUS server may optionally be 

31 protected with IP security. The establishment of the security association is outside the scope of 

32 this specification. 

33 When the PDSN sends a RADIUS Access-Request message, it may include both IPv4 and IPv6 

34 specific attributes and/or VSAs. This is because the PDSN may not know a priori whether the MS 

35 intends to use IPv4, IPv6, or both, since the address assignment does not occur until after 



The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the service 
option number connected to the PDSN. 
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1 RADIUS authentication and authorization has completed. As per RFC 3162, the IPv6 attributes 

2 may be sent along with IPv4-related attributes within the same RADIUS message. The PDSN 

3 decides to use IPv4 and/or IPv6 specific attributes and/or VSAs that it receives in the RADIUS 

4 Access-Accept message based on whether the MS initiates IPCP and/or IPv6CP. 

5 3.2.2.1 NAI Construction in the Absence of CHAP or PAP 

6 In the event that the MS does not negotiate CHAP or PAP, no MS NAI is received by the PDSN. 

7 In this case, the PDSN shall not perform additional authentication of the user. If the PDSN is 

8 capable of constructing a properly formatted NAI based on the MSID, using the syntax defined in 

9 RFC 2486, then accounting records shall be generated and keyed on the user's constructed NAI. 

10 The NAI shall be constructed using the syntax defined in RFC 2486, in the form 

1 1 <MSID>@<realm>, where <MSID> is the MSID of the MS, and <realm> is the name of the home 

12 network that owns the MS's MSID. If the PDSN is unable to construct an NAI for an MS, then the 

1 3 PDSN may deny service to the MS. 

14 The PDSN shall use one of the following MSID formats to construct the NAI, as provided by the 

15 RN: 

16 • International Mobile Subscriber Identity (IMSI) [E.212]; 

17 • Mobile Identification Number (MIN) [3]; 

18 • International Roaming MIN (IRM) [2]. 

19 The PDSN shall store the constructed NAI into the accounting records, and the Visited RADIUS 

20 server may use the realm to forward these records to the correct Home RADIUS Server for 

21 proper summary and settlement 7 . The constructed NAI shall not be used for authentication. If 

22 configured by the operator, the PDSN shall send RADIUS accounting messages to the Visited 

23 RADIUS server using the constructed NAI in the absence of CHAP or PAP. 

24 3.2.3 Ingress Address Filtering 

25 For IPv4, the Serving PDSN shall check the source address of every packet received on the PPP 

26 link from the MS. 

27 Upon receiving a packet from the MS with invalid 8 source IP address, the PDSN shall discard the 

28 packet and may send an LCP Configure-Request message to restart the PPP session 9 if IPCP 

29 has reached the open state. 

30 The PDSN shall send an LCP Configure-Request message to the MS if it continues to receive 

31 packets with invalid source IP address from the MS. 

32 For Mobile IP and simultaneous Simple IP and Mobile IP sessions see section 4.2.5. 

33 For IPv6, the Serving PDSN shall check the prefix of the source IP address of every packet 

34 received on the PPP link from the MS. If the prefix is not associated with the PPP Session of the 

35 MS, then the PDSN shall discard the packet and send an LCP Configure-Request to restart the 

36 PPP session. If the source address is the IPv6 unspecified address and the message type is 

37 Neighbor Solicitation for Duplicate Address Detection (DAD), then the PDSN shall silently discard 



7 The Home RADIUS Server may require an MSID to user conversion table to map the 
constructed NAI ( msid(gjreaim ) to the user's actual NAI ( user® realm ) to complete the billing 
process in cases where the constructed NAI differs from the actual NAI. 

The source IP address from the MS is considered as invalid if it is not one of the addresses that 
have been assigned to the MS or if the MS has not been assigned any IP addresses. 
9 The reason to restart PPP is because the user could have started a Simple IP session during a 
previous dormant handoff to another PDSN and returned; in this case the current PDSN would 
not know the MS had invoked Simple IP and received another IP address. Thus, restarting PPP 
will force the Simple IP session to get a topologically correct address. 
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1 the packet received from the MS. If the source address is the IPv6 unspecified address for 

2 purposes other than Duplicate Address Detection (DAD) or the source address is the MS's IPv6 

3 link-local address, the PDSN shall respond according to RFC 2461 . 

4 3.3 RADIUS Server Requirements 

5 The RADIUS Server shall follow the guidelines specified in RFCs 2865, 2866, and 31 62. 

6 The Visited and Home RADIUS server shall support the attributes as specified in Table 1 and 

7 X.S001 1-005-C, the Interim Accounting Record as described in Annex A of Chapter X.S001 1- 

8 005-C as well as the accounting attributes listed in X.S001 1-005-C. 

9 The Home RADIUS server may include the Always On' attribute in the RADIUS Access-Accept 

10 message to indicate an "Always On Service" for a user, based on the User Profile. 

1 1 If the MS uses CHAP or PAP, the PDSN sends the Visited RADIUS server a RADIUS Access- 

12 Request message with CHAP or PAP authentication information. The Visited RADIUS server 

13 shall forward the RADIUS Access- Request message to the home network or a peer (e.g., a 

14 broker) if it does not have the authority to accept/deny the request. This is in accordance with 

15 RFC 2865. Upon receiving a RADIUS Access-Request message, the Home RADIUS server shall 

16 send a RADIUS Access-Accept message or RADIUS Access-Reject message to the Broker or 

17 Visited RADIUS server. The Visited RADIUS server shall send the received response to the 

18 PDSN. 

19 If the PDSN includes IPv4 and IPv6 specific attributes and/or VSAs in the RADIUS Access- 

20 Request message, the RADIUS server should include the IPv4 and/or IPv6 attributes as 

21 provisioned in the user profile (e.g. Framed-lnterface-ld, Framed-IPv6-Prefix etc.) and/or VSAs in 

22 the RADIUS Access-Accept message. 

23 Upon receiving RADIUS Accounting-Request records from the PDSN, the Visited RADIUS 

24 server shall forward the RADIUS Accounting-Request records to the home or broker network. 

25 The communication between RADIUS client and RADIUS server or between RADIUS servers 

26 shall be protected using the secret shared with the next hop RADIUS server using the 

27 procedures described in RFC 2865. 

28 3.4 MS Requirements 

29 The MS may support Simple IP. The MS may choose Simple IP for IPv4 only, IPv6 only, or both 

30 IPv4 and IPv6 simultaneously. The MS shall access the cdma2000® 10 packet data service using 

31 the cdma2000air interface [5-9], [15]. 

32 3.4.1 PPP Session 

33 The MS shall use PPP as the data link layer protocol for Simple IP. 

34 3.4.1.1 Establishment 

35 If the MS supports multiple service instances, refer to X.S001 1-004-C for details of PPP 

36 negotiation. Otherwise, for a new PPP session, the MS shall use a service instance of SO type 

37 33/59 to perform PPP negotiation with the PDSN as described in RFC 1661 . 

38 PPP shall support control escaping in accordance with 4.2 of RFC 1662. The PPP Link Layer 

39 shall support negotiation of Asynchronous Control Character Mapping as defined in RFC 1662. 



10 cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the 
Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is 
a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States. 
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1 The MS should negotiate a control character mapping. If the MS negotiates control character 

2 mapping, it should attempt the minimum number of escapes by negotiating an ACCM of 

3 0x00000000. 

4 3.4.1.2 Termination 

5 When the MS deactivates packet data service, the MS should send an LCP Terminate-Request 

6 message to the PDSN to gracefully close the PPP session before releasing the packet data 

7 service option connections with the RN. In the case of power-down registration [5-9], the MS shall 

8 not send an LCP Terminate-Request message to the PDSN. 

9 3.4.1.3 Authentication 

10 The MS shall support CHAP and may support PAP authentication for Simple IP. If the MS is 

1 1 configured to not use CHAP and PAP, the MS shall respond with an LCP Configu re-Reject 

12 message containing the Authentication-Protocol option proposed in the LCP Configu re-Request 

13 message received from the PDSN. 

14 If the MS uses PAP, it shall respond to an LCP Configu re- Request message for CHAP with an 

15 LCP Configure-Nak proposing PAP. 

16 For both CHAP and PAP, the MS shall send an NAI in the form of user@realm. 

17 3.4.1.4 Addressing with IPCP 

18 The MS may support simultaneous operation of IPCP and IPv6CP. 

19 The MS may implement RFC 1877 in order to auto-configure DNS server IP addresses. The MS 

20 may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The MS 

21 may use default of zero for DNS server address negotiation. 

22 3.4.1.4.1 IPv4 Addressing 

23 For IPv4, the MS should send an IP address of 0.0.0.0 during the IPCP phase to request an IP 

24 address from the network. The MS shall accept the address provided by the PDSN. If the MS 

25 requests a non-zero IP address during the IPCP phase, the PDSN shall reply with an IPCP 

26 Configure-Nak in response to the request in order to propose a different IP address. The MS 

27 shall accept the new address, and shall send an IPCP Configure-Request to the PDSN with the 

28 new IP address. 

29 3.4.1.4.2 IPv6 Addressing 



30 For IPv6, the MS shall support the following RFCs, with exceptions as noted in this specification: 

31 • An IPv6 Aggregatable Global Unicast Address Format [RFC 3587]; 

32 • Internet Protocol, Version 6 (IPv6) Specification [RFC 2460]; 

33 • Neighbor Discovery for IP Version 6 (IPv6) [RFC 2461]; 

34 • IPv6 Stateless Address Autoconfiguration [RFC 2462]; 

35 • Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 

36 (IPv6) Specification [RFC 2463]; 

37 • IP Version 6 over PPP [RFC 2472]; 

38 • IP Version 6 Addressing Architecture [RFC 3513]. 

39 The MS should support Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 

40 3041]. To avoid disruption of an active session, e.g., Voice over IP, the MS should not change the 

41 IPv6 address used for that session. 
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1 For IPv6, the MS shall perform interface-identifier negotiation as described in RFC 2472. The MS 

2 shall construct the link-local IPv6 address by pre-pending the link-local prefix FE80:: /64 [RFC 

3 3513] to the interface identifier negotiated during the IPv6CP negotiation phase [RFC 2472]. 

4 When the Interface-Identifier is negotiated in the IPv6CP phase of the PPP session setup, the MS 

5 should not perform duplicate address detection for the link local address as part of IPv6 stateless 

6 address auto-configuration [RFC 2462]. 

7 The MS shall construct global IPv6 addresses by pre-pending the prefix received from the Router 

8 Advertisement messages (see the following paragraph) to the interface identifier negotiated 

9 during the IPv6CP negotiation phase [RFC 2472] or to the interface identifiers generated using 

10 techniques defined in RFC3041 . The MS should not perform Duplicate Address Detection for 

1 1 global IPv6 addresses (since the prefix used is a globally unique /64 and exclusive to the PPP 

12 session). 

13 Following the successful IPv6CP phase and auto-configuration of link-local address, the MS may 

14 transmit a Router Solicitation (RS) message(s) if a Router Advertisement message has not been 

15 received from the PDSN within a random amount of time between 0 and 

1 6 MAX_RTR_SOLICITATION_DELAY seconds per RFC 2461 . 

1 7 The MS may set the upper bound of the delay to a value greater than that specified by the 

1 8 constant MAX_RTR_SOLICITATION_DELAY in RFC 2461 . The MS may also set the lower 

19 bound of the delay to a value greater than 0. The MS may set the configurable number of RS 

20 messages to a value less 11 than that specified by the constant MAX_RTR_SOLICITATIONS in 

21 RFC 2461 . The MS may set the interval between the configurable number of RS messages to a 

22 value less 11 than or greater than that specified by the constant RTR_SOLICITATION_INTERVAL 

23 in RFC 2461. 



24 If the last RS message is sent and a RA message is not received after a router solicitation 

25 interval, the MS shall send an IPv6CP Configure-Terminate message to the PDSN. Upon 

26 reception of a RA message from the PDSN that contains the /64 globally unique prefix, the MS 

27 shall perform stateless address auto-configuration for global IPv6 addresses as per RFC 2462 

28 (and RFC 3041 for privacy purposes). 

29 After establishment of a PPP link with the PDSN, the MS shall treat that PDSN as the default 

30 router until the PPP session is closed. 

31 3.4.1.5 Compression 

32 The MS shall support Van Jacobson TCP/IP header compression [RFC 1 144]. The MS 

33 additionally may support the following header compression algorithms: 

34 • IP Header Compression [RFC 2507] with IP Header Compression over PPP [RFC 

35 2509]; 

36 • ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed [RFC 

37 3095] with ROHC over PPP [RFC 3241]; 

38 • ROHC: A Link Layer Assisted Profile for IP/UDP/RTP [RFC3242]; 

39 • Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer 

40 Assisted RObust Header Compression (ROHC) Profile [RFC3408]; 

41 • Compressing IP/UDP/RTP headers on links with high delay, packet loss and 

42 reordering [RFC 3545] with IP Header Compression over PPP [RFC 3544]. 

43 The MS shall use IPCP and/or IPv6CP to negotiate with the PDSN one or more header 

44 compression capabilities. 



11 This exception is allowed by this standard to optimize IPv6 RA over the cdma2000 wireless 
links. 
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1 If the MS is able to process received compressed header packets from the PDSN using various 

2 header compression protocols, the MS shall include the appropriate configuration option(s) to 

3 indicate to the PDSN which IP Header Compression protocol it supports in IPCP or IPv6CP 

4 Configure-Request message as defined by RFC 1332, RFC 3241 , RFC 2509, and RFC 3544. 

5 The MS shall support the PPP Compression Control Protocol [RFC 1962]. If the MS uses PPP 

6 payload compression, the MS shall use PPP Compression Control Protocol to negotiate a PPP 

7 payload compression algorithm, and the MS may support 12 PPP payload compression. 

8 3.4.1.6 PPP Framing 

9 The MS shall use the octet-synchronous framing protocol defined in RFC 1662. One exception is 

10 there shall be no inter-frame time fill (i.e., no flag octets shall be sent between a flag octet that 

1 1 ends one PPP frame and the flag octet that begins the subsequent PPP frame) 13 . 

12 3.4.1.7 PPP Link Status Determination 

13 To support Always On service, the MS shall adhere to RFC 1661 section 5.8 "Echo-Request and 

14 Echo-Reply" with regards to LCP Echo-Request message processing, and the MS should 

15 support the 3GPP2 vendor specific Max PPP Inactivity Timer value packet [RFC 2153]. 

16 Upon receiving a Max PPP Inactivity Timer packet, the MS shall send a reply and should use the 

17 value received in the packet to maintain Always On connectivity. 

18 The MS shall reset the Max PPP Inactivity Timer when a PPP frame is sent or received. 

1 9 Upon expiration of the Max PPP Inactivity Timer, the MS may initiate a new PPP session, or may 

20 enter the inactive state. 
21 



12 The MS shall not send compressed PPP frames when Multiple Service Instances are 
connected. 

13 If the MS consists of a laptop and a relay-model handset, the laptop may send inter-frame time 
fill that prevents the mobile from becoming dormant. 
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1 4 Mobile IPv4 Operation 

2 This section describes the requirements and procedures for Mobile IP operation for IPv4 [RFC 

3 2002-2006]. In this specification, Mobile IP refers to a service in which the user is able to 

4 maintain a persistent IP address even when handing off between RNs connected to different 

5 PDSNs. Mobile IPv4 provides the user IP routing service to a public IP network and/or secure IP 

6 routing service to private networks. 

7 4.1 Common Service Specification 

8 The common requirements for several network elements (e.g., PDSN and MS) for Mobile IP 

9 operation are described here. 

10 4.1.1 PPP Session 

11 See Section 3.1.1. 

12 For Mobile IP, neither CHAP nor PAP should be performed. If CHAP or PAP is performed, longer 

13 initial setup time and re-establishment time will occur as the result of an additional AAA traversal. 

14 Note that the MN-FA Challenge Extension procedures [RFC 3012] are performed regardless of 

1 5 whether or not CHAP/PAP is performed . 

16 4.1.2 Mobile IP 

17 The following standards shall be used for Mobile IPv4 operations with any limitations or 

18 extensions described in this specification: 

19 • RFC 2002-2006; 

20 • Reverse Tunneling [RFC 3024]; 

21 • Foreign Agent Challenge/Response [RFC 3012]; 

22 • NAI Extension [RFC 2794]. 

23 4.1.3 Dynamic Home Agent and Home Address Assignment 

24 In this specification, an MS may request dynamic HA and/or Home Address assignment during 

25 the initial MIP registration according to the following scenarios of Table 2 and Table 3 (and also 

26 see section 4.5.2.2). 

27 If the network receives an RRQ from the MS with an HA Address value of 0.0.0.0, the network 

28 shall treat the value as 255.255.255.255 (see section 4.5.2.2). 



Scenarios 


Type of Request 


Home Address 
specified in RRQ 


Home Agent 
Address specified in 
RRQ 


Scenario 1 


Dynamic case 


0.0.0.0 


255.255.255.255 or 
0.0.0.0 


Scenario 2 


Semi-static case 


x.x.x.x 


255.255.255.255 or 
0.0.0.0 


Scenario 3 


Semi-static case 


0.0.0.0 


y-y-y-y 


Scenario 4 


Static case 


x.x.x.x 


y.y.y-y 
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Table 2 - Home Agent and Home Address Scenarios 



Scenarios 




Scenario 1 


This is for dynamic Home Address assignment and a dynamic HA 
assignment. 


Scenario 2 


In this scenario, the Home RADIUS server shall assign an appropriate HA to 
the MS. The Home RADIUS server may use the specified Home Address to 
select an HA for the MS. 


Scenario 3 


This corresponds to dynamic Home Address assignment and static HA 
assignment. 


Scenario 4 


This is for static HA and static Home Address MIP registration, i.e., there is no 
dynamic assignment. 


Table 3 - Description of Scenarios 



2 

3 For details on dynamic HA assignment see the following: 

4 • Section 4.2.2.4 for the PDSN. 

5 • Section 4.3.4 for the HA. 

6 • Section 4.4.1 for the Home RADIUS server. 

7 • Section 4.5.2.2 for the MS. 

8 4.2 PDSN Requirements 

9 The PDSN shall support Mobile IPv4 operation. 

10 4.2.1 PPP Session 

1 1 The PDSN shall support multiple Mobile IP Home Addresses over a single PPP session. 

12 4.2.1.1 Establishment 

13 See Section 3.2.1.1. 

14 4.2.1.2 Termination 

15 The Serving PDSN shall close the PPP session if there is no established underlying R-P session 

16 or P-P session for the MS, respectively. The PDSN shall clear the R-P session and P-P session, 

17 whenever the PPP session is closed. If the PDSN receives IP packets destined to an MS for 

18 which there is no established PPP session for the MS, the PDSN shall silently discard the packet. 

1 9 If the PDSN receives a failure code in the RRP from the HA, then the PDSN shall deliver the RRP 

20 to the MS, and shall not close the PPP session before a configurable timer expires. If the PDSN 

21 generates a failure code, the PDSN shall deliver the RRP to the MS and shall not close the PPP 

22 session before a configurable timer expires. 

23 See Annex C for description of PPP Inactivity Timer and Session Timer. 

24 The PDSN may receive the Always On attribute with value '1' from the Home RADIUS server in 

25 order to activate the Always On service for a user. If the PDSN receives the Always On attribute 

26 with value '1 ', it shall send the indicator to the RN as indicated in [4]. 

27 If the MIP binding lifetime has expired for the Always On session and a MIP re-registration has 

28 not been received from the MS, the PDSN shall send an LCP Terminate-Request to the MS. 
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1 4.2.1.3 Authentication 

2 The PDSN shall initially propose CHAP in an LCP Configure- Request message to the MS. The 

3 PDSN shall re-send an LCP Configure- Request message without the authentication option after 

4 receiving the LCP Configu re-Reject (CHAP or PAP) from the MS. 

5 4.2.1.4 Addressing with IPCP 

6 When only Mobile IP service is requested by the MS and prior to the initial MIP registration, the 

7 MS shall not include an IP Address Configuration Option in the IPCP Configu re-Request 

8 message to the PDSN. If the MS includes an IP Address Configuration Option in the IPCP 

9 Configu re-Request to the PDSN, the PDSN considers this as an MS using Simple IP service. In 

10 this case, the PDSN shall send an IPCP Configure-NAK with a new proposed IP address for the 

11 MS. 

12 During IPCP phase, the PDSN shall include the IP Address Configuration option containing its IP 

13 address in the IPCP Configure-Request messages sent to the MS. 

14 The PDSN shall not support RFC 2290. If the PDSN receives an IPCP Configure-Request from 

15 the MS containing the Mobile IPv4 Configuration Option [RFC 2290], the PDSN shall reply with 

16 an IPCP Configure-Reject message. 

17 The PDSN shall implement the IPCP configuration options as defined in RFC 1877 for DNS 

18 server address negotiation. The PDSN shall negotiate Primary and Secondary DNS server IP 

19 addresses with the MS, if DNS Server Configuration options are received during the IPCP phase. 

20 4.2.1.5 Compression 

21 See Section 3.2.1.5. 

22 4.2.1.6 PPP Framing 

23 See Section 3.2.1.6. 

24 4.2.2 MIP Registration 

25 4.2.2.1 Agent Advertisements 

26 For the MS that uses Mobile IP, the PDSN shall begin transmission of an operator configurable 

27 number of Agent Advertisements immediately following negotiation or re-negotiation of PPP, or 

28 upon receipt of an Agent Solicitation message from the MS. Once the PDSN sends the 

29 configurable number of Advertisements, the PDSN shall not send further Advertisements, unless 

30 it receives an Agent Solicitation message from the MS. If the MS sends an RRQ to the PDSN, the 

31 PDSN shall cease sending Agent Advertisements. 

32 If the PDSN receives an Agent Solicitation from the MS following PPP establishment of a Simple 

33 IP session, the PDSN shall send Agent Advertisements to the MS with the 'R' bit set. The PDSN 

34 may also send an Agent Advertisement to the MS with the 'R' bit set if the PDSN receives a 

35 packet with an invalid IP source address 14 from the MS when the PDSN hasn't previously sent 

36 Agent Advertisements. If Agent Advertisements are being sent, the PDSN shall not restart 

37 sending the configurable number of Agent Advertisements. 

38 If the PDSN receives an RRQ with the 'D' bit set, the PDSN shall send an RRP with code 65 15 . In 

39 this case, the PDSN shall not close the PPP session. 

40 The Mobile IP Registration Lifetime field in the Agent Advertisement shall be smaller than the 

41 PPP inactivity timer value in use for the underlying PPP session. 



14 The source IP address from the MS is considered as invalid if it is not one of the addresses 
that have been assigned to the MS or the MS has not been assigned with any IP addresses. 

15 Previous version of this standard uses code 77. In this standard, the PDSN uses code 65, 
because code 77 is not used in RFC 2002. 
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1 Upon receiving a handoff indication including non-zero values of SID/NID/PZID of the previous 

2 PCFand SID/NID/PZID of the current PCF, if the PDSN already supports a Mobile IP service for 

3 the MS, the PDSN shall use this information to determine whether or not Mobile IP re-registration 

4 is required for the MS. If re-registration is required, then the PDSN shall re-negotiate PPP and 

5 begin transmission of an operator configurable number of Agent Advertisements. 

6 In order to minimize Agent Advertisements sent over the air, the PDSN shall not send unsolicited 

7 Agent Advertisements to an MS periodically to refresh the FA advertisement lifetime. The MS 

8 may send Agent Solicitations, when the FA advertisement lifetime expires. The Advertisement 

9 Lifetime is a configurable value, and shall be set to 9000 seconds (the maximum ICMP router 

10 advertisement lifetime). 

1 1 4.2.2.2 Addressing and Mobile IP 

12 The PDSN shall support RFC 2794, and therefore, support zero and non-zero Home Address 

13 values in the MIP RRQ. For dynamic Home Address assignment, the PDSN shall accept Mobile 

14 IP RRQs with a 0.0.0.0 source address from the MS, and shall use the NAI instead of the Home 

15 Address in it's pending registration request records, along with the Identification field [RFC 2794]. 

16 For dynamic Home Address assignment, the PDSN shall acquire the MS's Home Address from 

17 the Mobile IP RRP. 

18 In order to provide public network access and to provide private network access across the 

19 Internet, the PDSN shall use a publicly routable and visible IP address as a FA address. 

20 4.2.2.3 MIP Extensions 

21 The PDSN shall include the MN-FA Challenge Extension [RFC 3012] in the Agent Advertisement. 

22 Because Advertisements are rarely sent (to save air resources), the PDSN shall include in the 

23 RRP a new challenge that the MS should use in its next re-registration with this PDSN. On re- 

24 registration, the PDSN may communicate user FAC authentication information to the Home 

25 RADIUS Server, via broker servers if required, in a RADIUS Access-Request message. The 

26 frequency of this re-authentication and re-authorization is configurable by the operator. The 

27 challenge shall be changed on a serving access provider configurable basis. 

28 If the RADIUS attribute "MN-AAA Removal Indication" is included in the RADIUS Access-Accept 

29 message, and if the RRQ contains an MN-HA Authentication Extension followed by the MN-FA 

30 challenge and MN-AAA Authentication Extension, the PDSN shall remove the MN-FA challenge 

31 and the MN-AAA Authentication Extensions when relaying the RRQ to the HA. Otherwise, the 

32 PDSN shall relay the RRQ to the HA as received from the MS. 

33 4.2.2.4 Dynamic Home Agent Assignment 

34 The PDSN shall include the Home Address that it receives in the RRQ message from the MS in 

35 the RADIUS Access-Request message in RADIUS attribute 8 (Framed-IP-Address). The PDSN 

36 shall include the HA Address that it receives in the RRQ message from the MS in the RADIUS 

37 Access-Request message in the HA attribute (see X.S001 1-005-C). Upon receiving an RRP 

38 message with successful registration indication (code 0) for the MS, the PDSN shall update the 

39 mobility binding for the MS, which is indexed by the NAI and the Home Address (if non zero) in 

40 the RRQ, with the HA Address and the Home Address from the RRP. 

41 4.2.2.5 Private Network Support 

42 It is possible that two different MSs served by a PDSN have the same, overlapping private 

43 address because they belong to two different private networks. To support this scenario, the 

44 PDSN forms a logical association that contains the R-P Connection ID, the MS's Home Address, 

45 and the HA Address. When the PDSN receives a packet for a registered MS from the HA, the 

46 PDSN maps the MS's HA Address and the Home Address to one association, and transmits the 

47 packet on the R-P connection indicated by the R-P Connection ID of the association. 

48 When processing additional MIP registrations for the same MS, if the PDSN receives an RRP 

49 from a second HA that includes a private address as the Home Address, and if the private 
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1 address has already been assigned to the MS by another HA, the PDSN shall set the Code field 

2 to 65 (administratively prohibited) before forwarding the RRP to the MS. The first assigned 

3 address is not affected. 

4 4.2.2.6 Reverse Tunneling 

5 The PDSN shall reject a Mobile IP registration with an error code of 75, if a private Home 

6 Address as defined in RFC 1918 is present in either the RRQ or RRP, and the RRQ did not 

7 indicate reverse tunneling. 

8 If the Home RADIUS Server sends a Reverse Tunnel Specification attribute in the RADIUS 

9 Access-Accept message indicating that reverse tunneling is required, and the MS did not indicate 

10 reverse tunneling in the RRQ, the PDSN shall reject the registration with an error code of 75. 

1 1 If the MS negotiates reverse tunneling, then the PDSN shall tunnel both direct delivered and 

12 encapsulated packets back to HA. This applies to unicast, multicast, and broadcast IP destination 

13 addresses, even if the direct delivery mode is used. See Reverse Tunneling [RFC 3024] for an 

14 explanation of direct and encapsulated delivery styles. 

15 The PDSN shall support both direct delivered and encapsulated packets. 

16 4.2.3 RADIUS Support 

17 The PDSN shall act as a RADIUS client in accordance with RFC 2865. On initial mobile access, 

18 the PDSN shall communicate user FAC authentication information to the Home RADIUS Server, 

19 via the broker RADIUS servers if required, in a RADIUS Access-Request message. On receipt of 

20 the RRQ from the MS, and if SPI in the MN-AAA Authentication Extension is set to CHAP-SPI, 

21 the PDSN shall create a RADIUS Access-Request message in accordance with 

22 Table 4. See section 4.3.2 for how to construct CHAP-Password and CHAP-Challenge fields in 

23 the RADIUS Access-Request message. 

24 If the SPI in the MN-AAA Authentication Extension is set to CHAP SPI as per RFC 3012, the 

25 PDSN shall use MD5 when computing the CHAP challenge. If the authentication succeeds, the 

26 Home RADIUS server shall send a RADIUS Access-Accept message to the PDSN. If the 

27 authentication fails, the Home RADIUS server shall send a RADIUS Access-Reject message to 

28 the PDSN. 

29 The inclusion of the NAS-IP-Address or the NAS-IPv6-Address, or both in the RADIUS Access- 

30 Request message, depends on whether the PDSN has an IPv4 address or IPv6 address, or both. 

31 The PDSN shall act as a RADIUS accounting client in accordance with RFC 2866 and shall 

32 communicate user accounting information to the Visited RADIUS server in RADIUS Accounting- 

33 Request messages. The PDSN shall determine at completion of the IPCP phase that an 

34 Accounting-Request (Start) record shall be sent to the RADIUS server following a successful 

35 Mobile IP Registration Reply received from the HA. The Accounting-Request (Start) record shall 

36 contain the Account Session ID and Correlation ID attribute generated by the PDSN. 

37 The security of communications between the PDSN and the RADIUS server may be provided 

38 using IP security. The establishment of security is outside the scope of this specification. 

39 4.2.4 IP Security Support 

40 There may be a statically configured shared key for computing the Mobile IP HA-FA 

41 Authentication Extension in Mobile IP registration messages. If such a shared key exists, the 

42 PDSN and the HA shall use it. Additional Security Associations (SAs) between the PDSN and HA 

43 may also be supported for the protection of Mobile IP control messages and user data. This 

44 specification supports the following options for the establishment of such additional SAs: 

45 • Public certificates 16 . 



16 Refer to Annex A and B for details. 
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1 • Dynamic IKE pre-shared secret distributed by the Home RADIUS Server. 

2 • Statically configured IKE pre-shared secret. 

3 The PDSN shall support IPSec and IKE [RFC 2409]. An SA between the PDSN and the HA may 

4 be established using X.509 based certificates, or a pre-shared secret for IKE that may be 

5 statically configured or dynamically provisioned by the Home RADIUS server. Although ESP is 

6 preferred (and shall be implemented), AH shall also be implemented in order to maintain 

7 backward compatibility with previous versions of this specification. 

8 In the case of a carrier owned HA, and if mandated by carrier policy, the PDSN shall have a SA 

9 with the HA in order for a RRQ to be successfully processed. The SA may formally be via IPSec 

10 (i.e., ESP or AH) or Mobile IP HA-FA Authentication Extension. 

11 An SA between the PDSN and the HA shall be established as follows: 

12 When receiving a MIP RRQ containing a unicast HA Address, the PDSN shall verify if a SA 

13 currently exists with the HA. If an SA does not exist, the PDSN shall verify if HA X.509 certificates 

14 exists. If no HA X.509 certificate exists, the PDSN shall verify if a root certificate exists. If the 

15 necessary certificates do not exist, the PDSN shall verify if a statically configured pre-shared 

16 secret for IKE exists. If the static pre-shared secret for IKE is also not available, it shall include a 

17 request for a pre-shared secret for IKE in the RADIUS Access-Request message. The Home 

18 RADIUS server shall include the pre-shared secret for IKE and a KeylD in the RADIUS Access- 

1 9 Accept message if IPSec services are authorized for the user. 

20 When the MS uses dynamic HA assignment (scenarios 1 and 2 from Section 4.1.3), the PDSN 

21 shall always request the IKE pre-shared Secret from the Home RADIUS server. IPSec support 

22 for dynamic HA assignment is further described in Section 4.2.4.3. 

23 4.2.4.1 IPSec Service Authorized 

24 The PDSN shall provide IPSec services as indicated by the Security Level attribute included in 

25 the RADIUS Access-Accept message. The Security Level attribute included in the RADIUS 

26 Access-Accept message allows the Home RADIUS server to indicate whether IP security should 

27 be applied to MIP registration messages and MIP tunneled data between the HA and the PDSN, 

28 or not to use IPSec at all. The same security level shall be applied by the PDSN for all users 

29 using the same Home Agent. If the PDSN receives the deprecated value of '1' or '2', the PDSN 

30 shall use a default value of '3'. 

31 If the home network authorizes IPSec services, the PDSN shall not forward an RRQ to the HA 

32 unless an IPSec SA is established. The PDSN shall send a failed RRP with an error code of 65 

33 (Administratively Prohibited) to the MS if IPSec service is authorized by the Home RADIUS 

34 Server but it is unable to establish an IPSec SA to the HA. The Home RADIUS Server authorizes 

35 the PDSN to either use an existing SA with the corresponding HA or to establish a new SA if no 

36 prior SA exists. 

37 If an IPSec SA does not exist and IPSec is authorized, the PDSN shall establish a SA using IKE 

38 with either X.509 or root certificates, or statically configured pre-shared secret for IKE, or 

39 dynamically distributed pre-shared secret for IKE. The PDSN shall comply with the specifications 

40 in IKE [RFC 2409] and the Annexes A and B in this specification. 

41 If reverse tunneling is required and IPSec security is authorized, then the PDSN shall provide 

42 security on the reverse tunnel. 

43 If the PDSN does not receive the Security Level attribute from the Home RADIUS server, and an 

44 IPSec SA to the HA already exists, the PDSN shall continue to use the same SA. If it receives a 

45 new pre-shared secret for IKE and an SA already exists, the PDSN shall not renegotiate the 

46 ISAKMP SA and shall discard any pre-shared secret received in the RADIUS Access-Accept 

47 message. If no SA exists, then the PDSN shall follow local security policy. 

48 If an IPSec SA already exists with the HA, the PDSN shall ensure the IPSec SA is maintained by 

49 periodically refreshing the SA for as long as valid Mobile IP bindings exist with that HA. 
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1 4.2.4.2 IPSec Service Not Authorized 

2 If the Home RADIUS server does not authorize security for the MS, the PDSN shall not delete 

3 existing IPSec SA with an HA. This is because IPSec should be authorized per PDSN-HA pair 

4 and thus other MSs may be using the same IPSec SA. 

5 4.2.4.3 Dynamic HA Assignment 

6 When the PDSN receives a MIP RRQ containing a HA Address of 255.255.255.255 (or 0.0.0.0), 

7 it shall always include the IKE Pre-shared Secret Request attribute in the RADIUS Access- 

8 Request message sent to the Home RADIUS server. The Home RADIUS server responds with a 

9 RADIUS Access-Accept message containing the allocated HA Address and if IPSec services are 

10 authorized for the user, the corresponding dynamic pre-shared secret and KeylD for IKE are also 

1 1 included. The PDSN shall verify if IPSec services are authorized by the presence of the Security 

12 Level attribute. When IPSec service is authorized for the user, the PDSN shall then determine 

13 from the received HA Address whether an IPSec SA already exists. If an SA already exists with 

14 the HA, the PDSN shall use the existing SA as is and shall discard any pre-shared secret 

15 received in the RADIUS Access-Accept message. 

16 If an SA does not exist, the PDSN shall determine if certificates or static pre-shared secret for IKE 

17 exist for the HA, otherwise the pre-shared secret for IKE, if provided by the Home RADIUS 

18 server, shall be used to establish the required SA. 

19 4.2.5 Ingress Address Filtering 

20 Upon receiving a packet from the MS, the PDSN shall discard the packet if one of the following 

21 conditions holds: 

22 • the packet is received while the PPP negotiation is in progress (state is not open), 

23 • the packet is received while MIP registration is pending 17 , but the source IP address 

24 of the packet is invalid 18 , and the packet is not a MIP control packet (MIP RRQ or 

25 Agent Solicitation). 

26 For a Mobile IP session establishment over a Simple IP session, at the Simple IP establishment, 

27 1 . if the MS sends an Agent Solicitation to the PDSN, the PDSN shall respond with an 

28 Agent advertisement and shall discard all IP packets with an invalid source IP 

29 address while MIP registration is pending 17 . 

30 2. If the MS doesn't send Agent Solicitations but sends IP packets with an invalid 

31 Source IP address, the PDSN may discard the packets and may send an Agent 

32 Advertisement to the MS. If the PDSN sends Agent Advertisements to the MS as a 

33 result of an Invalid Source IP address, it shall discard all IP packets with an invalid 

34 source IP address while MIP registration is pending 17 . 

35 If the MS fails to register with the PDSN and continues to send IP packets with invalid source IP 

36 address, the PDSN shall discard the packets and shall send an LCP Configure-Request 

37 message to the MS to renegotiate the PPP session. 

38 4.3 Home Agent Requirements 

39 The HA shall support MIP [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC 3012], 

40 and Mobile IP NAI Extension [RFC 2794]. In order to provide public network access and private 

41 network access across the public network, the HA shall use a globally routable and visible IP 

42 address. 



17 i.e., between the NCP open state and completion of MIP registration. 

18 The source IP address from the MS is considered as invalid if it is not one of the addresses 
that have been assigned to the MS or if the MS has not been assigned any IP addresses. 
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1 4.3.1 Multiple Registrations 

2 The HA shall support Multiple registrations with the same NAI but different static Home 

3 Addresses. 

4 4.3.2 MIP Authentication Support 

5 When the HA receives an RRQ from a PDSN, it authenticates the RRQ using the MN-HA shared 

6 key. At initial registration, if the HA does not have the MN-HA shared key, it shall retrieve the MN- 

7 HA shared key from the Home RADIUS server. Based on the policy of the home network, the HA 

8 may also process the MN-AAA Authentication Extension as specified in RFC 3012, if included in 

9 the RRQ. 

10 If the home network policy dictates that the HA shall process the MN-AAA Authentication 

1 1 Extension, then the HA shall authenticate the request by including the following attributes in a 

12 RADIUS Access-Request message to the Home RADIUS server: 

13 • User-Name (1) = MN-NAI field in the MN-NAI Extension 

14 • CHAP-Password (3) = 

15 > CHAP Ident field = High-order byte of the Challenge Field in the MN-FA 

16 Challenge Extension 

17 > String field = Authenticator field from the MN-AAA Authentication 

18 Extension 

19 • CHAP-Challenge (60) = MD5 (Preceding MIP RRQ, Type, Subtype, Length, SPI), 

20 followed by the least-order 237 bytes of the Challenge Field in the MN-FA Challenge 

21 Extension. The MD5 checksum is computed over the MIP RRQ data preceding the 

22 MN-AAA Authentication Extension and the Type, Subtype, Length, SPI fields of the 

23 MN-AAA Authentication Extension. 

24 • MN-HA SPI = to request the MN-HA shared key if not available at the HA. The MN- 

25 HA shared key corresponds to a single user's NAI, or NAI and non-zero static IP 

26 address pair. 



27 If the MN-AAA Authentication Extension is not present in the RRQ or HA policy dictates that the 

28 HA shall not process the MN-AAA Authentication Extension (, and the HA requires the MN-HA 

29 shared key from the RADIUS server), the HA shall send a RADIUS Access-Request 19 message 

30 that includes a User Name, a User-Password and an MN-HA SPI. 

31 If the MN-HA shared key is requested, the Home RADIUS server shall encrypt the MN-HA 

32 shared key in a RADIUS Access-Accept message using a method based on the RSA Message 

33 Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. 

34 The HA shall save the MN-HA shared key received from the Home RADIUS server for the 

35 duration of the MIP session with the MS. Based on the local policy, the HA may store the MN-HA 

36 shared key a certain time skew after releasing the mobility binding for the MS. 

37 The HA shall compute the MN-HA Authentication Extension, according to RFC 2002, based on 

38 the MN-HA shared key. Computation of the extension shall include the Type and the SPI field of 

39 the MN-HA Authentication Extension itself. 

40 4.3.3 IPSec Support 

41 The HA shall determine which type of security associations (if any) are required with a PDSN. 

42 The HA and the PDSN shall use the same security policy as specified in the Home RADIUS 



19 Construction of the message is implementation dependent. 
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1 server. The policy may be locally configured at the HA or may be obtained from the Home 

2 RADIUS server. 

3 If IPSec is authorized and no SA is currently in place, the HA shall participate in IKE negotiation 

4 with the PDSN. The negotiation will result in establishing an IPSec SA that will be used for all 

5 traffic between the HA and the PDSN. 

6 The HA shall perform a similar operation as the Home RADIUS server to generate the pre-shared 

7 secret for IKE (i.e., K), see algorithm for K in Section 4.4.3. 

8 When an IKE request is received, the HA shall validate the timestamp in the KeylD field. This 

9 timestamp eliminates the possibility of re-using a previously generated shared-key for IKE 'K 

10 value while the secret key 'S' is still valid on the HA. The HA shall also use the 'S' Key indexed by 

1 1 Home RADIUS server IP address from the KeylD field. 

12 If there is no previously assigned 'S' Key, the S Key is not found, or the timestamp in the KeylD is 

13 greater than the 'S' expiration time, then the HA shall send a RADIUS Access-Request message 

14 to the Home RADIUS server to request the S Key. 

15 That RADIUS Access- Request message shall contain: 

1 6 • The User-Name attribute consisting of a concatenation of the PDSN's CoA and HA 

17 Address. 

18 • The 'S' Request attribute. 

19 The User-Name attribute should be formatted using ASCII hexadecimal notation. Both addresses 

20 are converted to hexadecimal and the ASCII codes of the hexadecimal characters and are 

21 concatenated with the HA Address following the CoA. For example, CoA of 10.10.10.1 1 is 

22 concatenated with an HA Address of 92.64.10.1 to yield "0A0A0A0B5C400A01 ". 

23 The RADIUS Access-Accept message from the Home RADIUS server shall include the 'S' Key 

24 and its lifetime, and may include the Security Level attribute. The HA shall save the 'S' Key 

25 received from the Home RADIUS servers. The HA shall compute the pre-shared secret "K" using 

26 KeylD (X.S001 1-005-C) and the 'S' Key (see Section 4.4.3). 

27 Each HA shall have a configurable, allowable time skew to be used to validate the freshness of 

28 'K. The HA shall maintain expired 'S' keys for a configurable amount of time. This expired key 

29 shall be used when KeylDs are received that refer to the expired 'S' Key but falls within the 

30 allowable time skew 20 . 

31 The security method used between the HA and the Home RADIUS server is outside the scope of 

32 this specification. 

33 However, the Home RADIUS server may encrypt the 'S' Key and the 'S' Lifetime using a method 

34 based on the RSA Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of 

35 RFC 2868. 

36 If mandated by an operator security policy, an operator's HA shall have a SA with the PDSN in 

37 order for a registration request to be successfully processed. The SA may formally be via IPSec 

38 (e.g., ESP or AH) or via a Mobile IP HA-FA Authentication Extension. Likewise, a HA shall accept 

39 or reject a RRQ received directly from an MS with a 'D' bit set depending on security policy. 

40 4.3.4 Dynamic Home Agent Assignment 

41 During dynamic HA assignment, the HA Address that is specified by the MS in the RRQ message 

42 and the IP address of the dynamically assigned HA may not be the same. Upon receipt of such a 



20 The skew serves to solve the case where RADIUS or IKE messages are lost and must be 
transmitted yet the 'S' Key expires in the meantime. An example of the skew could be one 
minute. 
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1 RRQ message in an IP packet with the destination IP address set to the HA unicast IP address, 

2 the HA may accept the RRQ contrary to the specification in RFC 2002 or may reject it with an 

3 error code of 1 36 in accordance with RFC 2002. The HA shall follow the procedures described in 

4 Section 4.3.2 to complete its authentication process for the RRQ message. The HA shall put its 

5 IP address in the HA Address field of the RRP message to the MS. 

6 4.4 RADIUS Server Requirements 

7 See Section 3.3. 

8 In order to provide the functions defined in this specification, the Home and Visited RADIUS 

9 servers shall support as required the attributes listed in Table 4 and X.S001 1-005-C, in addition 

10 to the standard RADIUS attributes. The Broker RADIUS server shall support the decryption and 

1 1 re-encryption of the Pre-shared Secret attribute and the MN-HA Shared Key attribute. 

12 



Attribute Name 


Type 


Access - 
Request 


Access - 
Accept 


Interface(s) 


User-Name 


1 


M 


M 


PDSN -> AAA 
HA -> AAA 


— 

User-Password 


— 

-= 


— — — 

O Note 1 




l_l A s AAA 
MA -> AAA 


CHAP-Password 




M Note 2 




DHCM s AAA 
rUolN -> AAA 

UA -> AAA 
rlA AAA 


CHAP-Challenge 


60 


M Note 2 




PDSN -> AAA 

U A s AAA 
HA -> AAA 


MAC ID A/J/Jcorp 
INAo-lr-AuureSS 


— 




— — — 

O Note 3 




nnQM --» AAA 
rUolN -> AAA 


MAC IDwfi AHHracc 

iNMo-ir vo-Aaaress 




KJ INOie 4 




pnCM AAA 
rUolN AAA 


Foreign Agent Address 


9KT7Q 








DnQM -> AAA 
rUolN AAA 


Correlation ID 


~S\ 


~M 

-J^ 


— 


DnQM <? AAA 
rUolN AAA 


Calling-Station ID 


okfi 




— ■■ 


DnQM ^» AAA 
rUolN AAA 


Home Agent 


_|b/7 


M 


— 

"7? 


DnQM <? AAA 
rUolN <---> AAA 


Framed-IP-Address 




""m 




DnQM AAA 

rUoN <-> AAA 


IKE Pre-shared Secret Request 


26/1 


Q 


— 


pnQM > AAA 
rUolN AAA 


Security Level 


26/2 




0 


AAA -> PDSN, 
AAA -> HA 


Pre-shared Secret 


26/3 




0 


AAA -> PDSN 


Reverse Tunnel Specification 


26/4 




0 


AAA -> PDSN 


Key ID 


26/8 




0 


AAA -> PDSN 


■S" Key 


26/54 




0 


AAA -> HA 


'S' Lifetime 


26/56 




0 


AAA -> HA 


'S' Request 


26/55 


O 




HA -> AAA 


MN-HA Shared Key 


26/58 




0 


AAA -> HA 


MN-HA SPI 


26/57 


0 




HA -> AAA 


Allowed Differentiated Services 
Marking 


26/73 




0 


AAA -> PDSN 


DNS Update Required 


26/75 




0 


AAA -> HA 


Always On 


26/78 




0 


AAA -> PDSN 


Service Option Profile 


26/74 




0 


AAA -> PDSN 


Remote IPv4 Address 


26/59 




0 


AAA -> PDSN 


Remote IPv6 Address 


26/70 




0 


AAA -> PDSN 


Remote Address Table Index 


26/71 




0 


AAA -> PDSN 


MN-AAA Removal Indication 


26/81 




0 


AAA ->PDSN 


NAS-Port-Type 


61 


O Note 5 




PDSN -> AAA 



13 (M) Indicates Mandatory attribute 

14 (O) Indicates optional attribute 



23 



X.S0011-002-Cv1.0 



1 Note 1 : The password is configured between the HA and the AAA. 

2 Note 2: For Mobile IP, this attribute is mandatory for the PDSN, and optional for the HA. 

3 Note 3:This is the IPv4 of the RADIUS server interface of the PDSN; at least one of NAS-IP- 

4 Address or NAS-IPv6-Address must be included. 

5 Note 4: This attribute is included if the PDSN supports IPv6 addressing. 

6 Note 5: The values are as follows: 22 (IS-2000) [5-9] or 24 (HRPD) [15], depending on the 

7 service option number connected to the PDSN. 

8 Table 4 - Occurrence of RADIUS Attributes for Mobile IP 

9 4.4.1 Dynamic Home Agent Assignment 

10 The Home RADIUS server shall implement an HA selection algorithm to perform dynamic HA 

1 1 assignment. The implementation details of this algorithm are outside the scope of this 

12 specification. The HA selection algorithm shall satisfy the four scenarios described in Section 

13 4.1.3. The Home RADIUS server shall return the assigned HA Address in the HA attribute in the 

14 RADIUS Access-Accept message to the PDSN. 

15 4.4.2 MN-HA Shared Key Distribution 

16 Upon receipt of a RADIUS Access- Request message from a HA containing the MN-HA SPI 

17 attribute, the RADIUS server shall send a RADIUS Access-Accept message containing the MN- 

18 HA shared key encrypted using a method based on RSA MD5 [RFC 1321] as described in 

19 Section 3.5 of RFC 2868. 

20 4.4.3 IKE Pre-shared Secret Distribution Procedure 

21 When the RADIUS Access-Request message is received from the PDSN containing the IKE Pre- 

22 shared Secret Request attribute, and IPSec services are authorized for the user, the Home 

23 RADIUS server shall distribute a key identifier and pre-shared secret for IKE to the PDSN using 

24 the Pre-shared Secret and KeylD attributes in the RADIUS Access-Accept message. The Home 

25 RADIUS server generates a pre-shared secret for IKE by processing the Home RADIUS IP 

26 address, FA IP address, and a timestamp as well as a secret key, known as the 'S' Key, through 

27 the HMAC-MD5 hashing algorithm. The 'S' Key is known between the Home RADIUS server and 

28 the HA. The 'S' Key is retrieved by the HA from the Home RADIUS server and has a configurable 

29 lifetime. The lifetime of the 'S' Key is a Home RADIUS local policy, and is based on the 

30 cryptographic strength of the 'S' Key. The pre-shared secret is generated using the following 

31 formula: 

32 K = HMAC-MD5 (Home RADIUS IP address | FA IP address | timestamp, 'S') 

33 The Home RADIUS server hides pre-shared secrets for IKE using a method based on the RSA 

34 Message Digest Algorithm MD5 [RFC 1321] as described in Section 3.5 of RFC 2868. 

35 4.5 MS Requirements 

36 The MS may support Mobile IPv4 service. The MS shall access cdma2000 packet data service 

37 using the cdma2000 air interface [5-9] and [1 5]. 

38 4.5.1 PPP Session 

39 The MS shall use PPP as the data link protocol for Mobile IP. The MS may support multiple 

40 Mobile IP Home Addresses over a single PPP session. 

41 4.5.1.1 Establishment 

42 Same as Section 3.4.1.1. 
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1 4.5.1.2 Termination 

2 Same as Section 3.4.1.2. 

3 If the MS tries to register and receives an RRP message with a failure code, it shall do one of the 

4 following: 



5 • Retry Mobile IP registration over the existing PPP session. 

6 • If existing Simple IP or Mobile IP sessions exist, give up on the failed Mobile IP 

7 registration and continue using the existing sessions. 

8 • Fall back to Simple IP by re-negotiating the PPP session. 

9 • Terminate the PPP session. 

10 4.5.1.3 Authentication 

1 1 The MS should not use CHAP or PAP for Mobile IP. When the MS receives an LCP Configure- 

12 Request message requesting CHAP authentication, the MS should reply with an LCP Configure- 

13 Reject message requesting no PPP authentication. If the MS receives an LCP Configure- 

14 Request message without the authentication option it shall respond with an LCP Configure-Ack 

15 message as described in RFC 1661. 

16 If CHAP is performed, performance degradation will occur as the result of an unnecessary AAA 

17 traversal, a FAC shall be performed regardless of whether or not CHAP is performed. The MS 

18 shall use the challenge received in the Agent Advertisement or RRP to compute the MN-AAA 

19 authenticator. 



20 As a further clarification to RFC 3012 section 8 (SPI For RADIUS Servers): 



21 If the challenge has fewer than 238 bytes, this algorithm includes the high-order byte in the 

22 computation twice, but ensures that the challenge is used exactly as is. Additional padding is 

23 never used to increase the length of the challenge; the input data is allowed to be shorter than 

24 237 bytes long. 



25 4.5.1.4 Addressing with IPCP 

26 If the MS uses Mobile IP only, the MS shall not use the IP Address Configuration Option [RFC 

27 1332]. On subsequent PPP session establishments while the MS intends to maintain a Home 

28 Address, the MS shall omit the option 21 . The MS shall not include the Mobile IPv4 Configuration 

29 Option in the IPCP Configure-Request messages sent to the PDSN. 

30 The MS may implement RFC 1877 in order to auto-configure DNS server IP addresses. The MS 



31 may negotiate Primary and Secondary DNS server IP addresses during the IPCP phase. The MS 

32 may propose a DNS server address of zero to indicate an explicit request that the PDSN 

33 provides the DNS server address information in a Configure-Nak. 

34 4.5.1.5 Compression 

35 Same as Section 3.4.1.5. 

36 4.5.1.6 PPP Framing 

37 Same as Section 3.4.1.6. 



21 If the MS that uses Mobile IP uses the IP Address Configuration Option [RFC 1332] to indicate 
the Home Address, the PDSN will consider it as an MS using Simple IP service and send a NAK 
with an alternative address to the MS. The MS will respond with an IP Configure Request with the 
alternative address. 
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1 4.5.2 MIP Registration 

2 4.5.2.1 Agent Discovery 

3 Immediately after a PPP session is established, the MS may send Agent Solicitations. In this 

4 case, the MS should use the same procedure as described in Section 2.4 of RFC 2002. If the MS 

5 does not have a Home Address, the MS shall use zero in the Source IP Address field of the IP 

6 packet that contains the Agent Solicitation. The MS shall support RFC 3012. 

7 4.5.2.2 Registration Messages 

8 Upon receiving Agent Advertisements from the PDSN, the MS shall send an RRQ message. 

9 The MS may request a non-zero home IP address belonging to its home IP network in the RRQ 

1 0 or indicate that the HA should dynamically assign it an IP address. If the MS requests a dynamic 

1 1 HA assignment, the MS shall set the HA Address to either 255.255.255.255 or 0.0.0.0. However, 

12 the MS should use 255.255.255.255. If the MS requests a static or already allocated HA Address, 

13 it should set the HA Address accordingly. 

14 The Home and HA Address allocations are based on the scenarios described in Section 4.1 .3. 

15 



Scenario 1 


To request a dynamic Home Address and a dynamic HA assignment, the MS shall 
set the Home Address field to 0.0.0.0 and the HA Address field to 255.255.255.255 
or 0.0.0.0 in the RRQ message. 


Scenario 2 


To request a dynamic HA assignment only while requesting a previously assigned 
Home Address, the MS shall set the Home Address field to the desired Home 
Address, and the MS shall set the HA Address field to 255.255.255.255 or 0.0.0.0 in 
the RRQ message. If the MS receives a failed RRP, the MS may retry a MIP 
registration under any of the scenarios. 


Scenario 3 


To request a dynamic Home Address allocation only while requesting a previously 
assigned HA, the MS shall set the Home Address field to 0.0.0.0 and the MS shall 
set the HA Address field to the desired HA Address in the RRQ message. If the MS 
receives a failed RRP, the MS may retry a MIP registration under any of the 
scenarios. 


Scenario 4 


When the MS is not requesting dynamic allocation of either a Home Address or a 
HA Address, the MS shall set the Home Address and HA Address fields with the 
desired IP addresses in the RRQ message. If the MS receives a failed RRP, the MS 
may retry a MIP registration under any of the scenarios. 



16 Table 5 - MS Registration Scenarios 

17 While requesting a dynamic Home Address assignment, the MS shall use zero in the Source IP 

18 Address field of the IP packet that contains the Mobile IP RRQ. In this case the NAI is used to 

19 identify the MS. 

20 During MIP re-registrations, the MS shall use the same HA Address and the Home Address that 

21 were assigned to it during the initial MIP registration. 

22 Upon receipt of an RRP message with successful registration indication (code 0) during initial 

23 registration, the MS shall accept the dynamically assigned HA Address contained in the RRP 

24 message, even if it is different from the HA Address provided in the RRQ message. 

25 If the MS had set up a Simple IP session and decides to run Mobile IP simultaneously using the 

26 FA function in the PDSN, it shall send an Agent Solicitation to the PDSN. Upon receiving an 

27 Agent Advertisement, the MS shall register with the PDSN and shall not use collocated CoA. The 

28 MS may also register directly with the HA using a collocated CoA obtained from Simple IP IPCP 

29 negotiation. 

30 If the MS desires reverse tunneling, the MS shall set the T-bit in the RRQ message. 



26 



X.S0011-002-Cv1.0 



1 The MS shall not set the V bit in the RRQ message. 

2 4.5.2.3 MIP Extensions 

3 The MS shall include the MN-NAI Extension [RFC 2794], MN-HA Authentication Extension [RFC 

4 2002], MN-FA Challenge Extension [RFC 3012], and MN-AAA Authentication Extension [RFC 

5 3012] in the RRQ message. Because advertisements are rarely sent to save air resources, when 

6 the MS performs re-registration, the MS shall use the challenge value contained in the last 

7 received RRP as described in RFC 3012. 

8 The MS shall compute the MN-AAA Authentication Extension, according to RFC 3012, based on 

9 the shared secret the MS has with the Home RADIUS server. The MS shall compute the MN-HA 

10 Authentication Extension, according to RFC 2002, based on the shared secret the MS has with 

1 1 the HA. Computation of the extension shall include the Type and SPI field of the MN-HA 

12 Authentication Extension itself. The MS may use the same shared-secret or different shared 

13 secrets in the computation of the MN-AAA Authentication Extension and MN-HA Authentication 

14 Extension. This is coordinated between the MS and its home network. 

15 4.5.2.4 Private Network Support 

16 If the MS wants private network access through Mobile IP, the MS shall use reverse tunneling. 

17 4.5.2.5 Termination 

18 When the MS wishes to terminate a MIP session, the MS may send a Mobile IP RRQ to the HA 

19 with a Registration Lifetime of zero to gracefully close the MIP session before terminating the 

20 packet data service with the RN 22 . 
21 



22 The MS should send the RRQ with a lifetime of zero to free resources such as public 
addresses in the HA. 



27 



X.S0011-002-Cv1.0 



1 5 Simultaneous Service 

2 The PDSN shall support, and the MS may support, any of the following simultaneous packet data 

3 session combinations: 

4 • Simple IPv4 service & Simple IPv6 service. 

5 • Simple IPv4 service & Mobile IPv4 service. 

6 • Simple IPv6 service & Mobile IPv4 service. 

7 • Simple IPv4 service & Simple IPv6 service & Mobile IPv4 service. 

8 Additionally, multiple Mobile IPv4 sessions may be operated simultaneously. Although any of 

9 these may run simultaneously, individual services are distinct. Within a single PPP session, the 

10 PDSN shall support simultaneous operation of IPCP [RFC 1332] and IPv6CP [RFC 2462]. 

1 1 Simultaneous services are supported through re-negotiation of IPCP, IPv6CP, or MIP as 

12 appropriate. 

13 Each packet data sessions shall be authenticated and authorized independently. In addition, 

14 each such session shall have unique accounting records. However, simultaneous Simple IPv4 

15 and Simple IPv6 share a common authentication and authorization procedure as described in 

16 Section 3.2.2. 
17 



28 



X.S0011-002-Cv1.0 



1 6 IP Reachability Service 

2 IP Reachability Service is the capability to update a DNS server in the home network with the 

3 current authorized MS IP address. When the MS desires to be reached by a DNS hostname, the 

4 Home RADIUS server (in the case of Simple IP or Mobile IP) or the HA (in the case of Mobile IP 

5 only) may send a DNS Update [RFC 2136] to a DNS server to add an A Resource Record for 

6 IPv4 and AAAA or A6 Resource Record for IPv6 [RFC 1886, RFC 2874 23 ]. 

7 The Update section of the DNS Update message contains the following values in 'Host address' 

8 Resource Type Resource Record: 

9 • Resource Name = username. realm 24 

10 • Resource Class = Internet address class 

11 • IP Address = newly assigned IP address 

12 The TTL (Time To Live) of the Update section in the DNS Update message should be zero so 

13 that all queries for the address are resolved using the up to date authoritative server for the user. 

14 This is because after the MS is assigned a different address, if the TTL were non-zero, the cache 

15 entry of the querying endpoint would no longer be valid, and, in fact, the address may have been 

16 g iven to a d ifferent MS . 

17 The security between the DNS Server and Home RADIUS server or the HA is outside the scope 

18 of this specification. 

1 9 The method used by the Home RADIUS server and/or HA to determine the IP address of the 

20 DNS server is outside the scope of this specification. 

21 IP Reachability Service as specified in this specification shall not be provided for users with 

22 single NAI and Multiple static Home Addresses. 

23 6.1 Simple IPv4 Operation 

24 The Home RADIUS server shall request that the DNS server add an A Resource Record for the 

25 user under the following conditions: 

26 • the Home RADIUS server receives a RADIUS Accounting-Request (Start) record 

27 containing the Beginning-Session VSA and the IP-Technology VSA indicates Simple 

28 IP, and 

29 • the Home RADIUS server is configured to send DNS Update messages, and 

30 • the user profile indicates that IP Reachability Service is enabled for the user. 

31 The Home RADIUS server shall send a request to the DNS server to delete the A Resource 

32 Record for a user under the following conditions: 

33 • the Home RADIUS server receives a RADIUS Accounting-Request (Stop) record 

34 from the PDSN currently serving the user, for a session, and the Session-Continue 

35 VSA is either absent or is included but the value is set to FALSE and the IP- 

36 Technology VSA indicates Simple IP. 



23 RFC 2874 is an experimental RFC as per RFC 3363 section 2.2. 

24 The MS sends the NAI as 'username @ realm', and the Home RADIUS Server converts the 
username@realm into 'username. realm'. When the HA performs DNS update, the HA shall 
convert the username@reaim to username.realm. 
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1 6.2 Mobile IP Operation 

2 The DNS server may be updated by either the Home RADIUS server or the HA. 

3 6.2.1 DNS Update by the Home RADIUS Server 



4 The Home RADIUS server shall request that the DNS server adds an A Resource Record for the 

5 user under the following conditions: 

6 • The Home RADIUS server receives an Accounting-Request (Start) record containing 

7 the Beginning Session VSA and the IP-Technology VSA indicates Mobile IP, and 

8 • the Home RADIUS server did not receive a RADIUSAccess-Request message from 

9 the HA with the DNS-Update-Capability VSA, and 

10 • the Home RADIUS server is configured to do DNS update, and 

11 • the user profile indicates that IP Reachability Service is enabled for the user. 

12 After performing DNS update for the user, the Home RADIUS server shall cache the User Name, 

13 NAS IP Address, and Framed IP address as received in the Accounting-Request (Start) record 

14 for the user. 

15 The Home RADIUS server shall send a request to the DNS server to delete the A Resource 

16 Record for a user under the following conditions: 

17 • The Home RADIUS server receives an Accounting-Request (Stop) record containing 

18 the IP-Technology VSA that indicates Mobile IP, and does not contain the Session- 

1 9 Continue VSA or the Session-Continue VSA is included but the value is set to 

20 FALSE, and 

21 • the Home RADIUS server has previously sent request(s) to the DNS server to 

22 add/update an A Resource Record for the corresponding user, and 

23 • the user profile indicates that IP Reachability Service is enabled for the user. 



24 6.2.2 DNS Update by the HA 

25 An HA that supports DNS update capability shall send a RADIUS Access-Request message to 

26 the Home RADIUS server at each initial MIP RRQ message it receives, and shall include the 

27 DNS-Update-Capability VSA. The home RADIUS server determines based on its configuration 

28 and user profile if the HA shall perform DNS update operations. The Home RADIUS server shall 

29 include the DNS-Update-Required VSA in the RADIUS Access-Accept message if the DNS- 

30 Update-Capability VSA was included in the RADIUS Access-Request message and it allows the 

31 HA to perform DNS update for the user. 

32 The HA shall request the DNS server to add an A Resource Record for a user under the following 

33 conditions: 



34 • The HA is capable of DNS update and it is configured to do so, and 

35 • the HA is authorized by the Home RADIUS server to perform DNS update, and 

36 • the Mobile IP Registration process is successful. 

37 The HA shall send a request to the DNS server to delete the A Resource Record for a user under 

38 the following conditions: 

39 • The HA has previously sent request(s) to the DNS server to add/update an A 

40 Resource Record for the corresponding user, and 

41 • the mobility binding for the user is set to expire due to the following reasons: 



30 



X.S0011-002-Cv1.0 



r 



The HA receives a Mobile IP RRQ with lifetime set to 0 from the user, or 



2 



r 



the Mobile IP registration lifetime for the user has expired, or 

the mobility binding for the user has been revoked by the FA or the HA, 
or 



3 
4 



r 



5 



r 



administrative reset. 



6 6.3 Simple IPv6 Operation 

7 For IPv6 IRS support, the Home RADIUS server shall use the Resource Records defined in RFC 

8 1886 as updated by RFC 2874 and RFC 3152. The operation of IRS service for IPv6 users is 

9 identical to the procedures described for Simple IPv4 in Section 6.1 . 

10 If the MS uses both IPv4 and IPv6, the Home RADIUS server shall request that the DNS server 

1 1 create or delete Resource Records for both IPv4 and IPv6. 



12 
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1 Annex A: IKE/ISAKMP Payloads 



2 This Annex addresses ISAKMP payloads in which multiple options exist (see RFC 2407-2409). 

3 The following requirements shall be met by the PDSN and HA, assuming IP security between the 

4 HA and PDSN is required. Payloads in which no options exist do not appear in this Annex. 

5 Note: If the HA (home network) does not require any security then Annex A does not apply nor 

6 does it apply to MSs using collocated CoA for Mobile IP. 

7 ISAKMP Fixed Header: 

8 The PDSN in this specification shall use a Major and Minor Version of 0. The HA shall 

9 minimally accept Major and Minor Version of 0. This specification does not make use of 

10 the Fixed Header Authentication (A) bit. 

11 Security Association Payload: 

12 All Security Association Payloads shall use the IPSec DOI. The Phase 1 ISAKMP 

1 3 Security Payload shall specify a situation of SIT_IDENTITY_ONLY. Phase 2 ISAKMP 

14 Security Payloads shall specify a situation of SIT_IDENTITY_ONLY for all cases where 

15 privacy or only authentication applies (as outlined in the PDSN and HA "IP Security" 

1 6 sections of this specification). 

17 Proposal Payload: 

18 Because the MS first makes contact with the PDSN, the PDSN shall be the Initiator of the 

19 Phase 1 ISAKMP SA. The HA shall be the Responder. The PDSN shall propose ISAKMP 

20 to the HA for the Phase 1 ISAKMP SA. 

21 For Phase 2 Quick Mode exchanges, both the PDSN and HA shall be Initiators and 

22 Responders because symmetrical, bi-directional security between the PDSN and HA is 

23 required. For message authentication, PDSNs conforming to this specification shall 

24 propose both AH 25 and ESP with the authentication option. The HA shall respond with 

25 ESP if the PDSN has proposed it. For message privacy, the PDSN shall propose ESP. 

26 For combined authentication and privacy, the PDSN shall propose ESP only. 

27 Mobile IP registration control packets and IP in IP tunneled packets may be protected by 

28 IPSec authentication, privacy, or both. Security policies to be used between the PDSN 

29 and the HA in this specification are dictated by the home network not the access provider 

30 network. The PDSN shall be capable of proposing authentication only, privacy only, and 

31 both authentication and privacy. Service provider owned HAs shall accept and propose 

32 only one of these, and the PDSN shall accept this proposal. The Home RADIUS server 

33 may deliver a User Profile to the Visited RADIUS server and PDSN that indicates 

34 whether security should be supported for IP in IP packets. If the Home RADIUS server 

35 indicates a request for no security on the IP-in-IP tunneled packets, the PDSN shall not 

36 delete existing IPSec security associations to the HA. This is because IPSec should be 

37 authorized per PDSN-HA pair and thus other MSs may be using those IPSec security 

38 associations. 

39 The SPI shall be four octets. 

40 Transform Payload: 

41 For Phase 1 , the PDSN shall use KEYJKE as the transform identifier. All 

42 implementations shall support 3DES and RSA. 



25 Note that a future version of this standard is likely to no longer require AH, in accordance with 
industry trends. 
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1 For Phase 2 Quick Exchange, the PDSN shall minimally support the ESP_3DES 

2 transform identifier within a Transform Payload for IPSec ESP Proposal Payload. It shall 

3 also support both HMAC-MD5 and HMAC-SHA1 as transform identifiers within a 

4 Transform payload for IPSec AH Proposal Payload. Service provider HAs shall likewise 

5 support these two transforms. The PDSN may optionally support and propose other 

6 transforms. An HA shall select one of the transforms offered by the PDSN. 

7 Key Exchange Payload: 

8 The PDSN and HA will exchange D-H (Diffie-Hellman) public values computed in the D-H 

9 group negotiated as part of a protection suite in the first message exchange of Phase 1 

10 for ISAKMP SA establishment. The PDSN shall specify Phase 1 authentication with 

1 1 certificates when the HA's certificate or HA's root CA certificate is available. 

12 Otherwise, if a Dynamic pre-shared IKE secret distributed by the Home RADIUS server is 

13 available, the PDSN shall specify Phase 1 authentication with a pre-shared secret mode 

14 of operation. In this case, the PDSN shall specify Phase 1 Aggressive mode only. This is 

15 necessary in order that the KeylD field can be transmitted in the clear. The Home 

16 RADIUS server shall insure that the value of the 'S' key is hard to guess (i.e., a properly 

17 generated random number) in order to prevent dictionary attacks that are possible with 

18 Aggressive mode. If the PDSN has a statically configured IKE secret for the SA with the 

19 HA, then the PDSN shall specify Phase 1 authentication with pre-shared secret mode of 

20 operation. In this case the PDSN may either use Main Mode or use Aggressive Mode. 

21 Identification Payload: 

22 For Phase 1 negotiation, the PDSN shall set the Protocol-Id field to zero or UDP. The 

23 port number shall be set to zero or 500. If the HA receives any other values for these two 

24 fields in the Identification Payload, IKE negotiation shall be aborted. 

25 For IKE authentication using pre-shared secret the PDSN and HA shall minimally support 

26 ID_KEY_ID in the ID Type field. For IKE authentication using Revised Public Key 

27 Encryption with RSA using X.509 certificates, the PDSN and HA shall minimally support 

28 ID_DER_ASN1_DN in the ID Type field. 

29 For Phase 2 (Quick Mode), both the PDSN and HA shall include the client identifiers in 

30 the form of optional Client Identification Payloads as specified in IKE (i.e., IDci and IDcr). 

31 To apply IPSec on all traffic between the PDSN and the HA, the PDSN and the HA shall 

32 exchange IDci and IDcr. The protocol and port number fields shall be "don't care" by 

33 setting them to 0 in both IDci and IDcr. The following is an example of the format of the 

34 client identifiers. 

35 IDCi: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, 

36 ldentification_data = PDSN_IPV4_ADDR. 

37 IDCr: Protocol field = 0, Port = 0, Idtype = ID_IPV4_ADDR, 

38 ldentification_data = HA_IPV4_ADDR. 

39 Certificate Payload: 

40 The Certificate Payload shall carry X.509 version 3 certificates. 

41 Signature Payload: 

42 The PDSN and HA shall not include this payload. 

43 Notification Payload: 

44 The Notification Payload carries error messages and reason codes regarding failure for a 

45 peer to be able to establish a security association. The PDSN and HA handling of a failed 

46 security association establishment is specified in the main body of the standard. 
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1 The PDSN and HA shall use the "SA Lifetime Notify" code as a trigger to refresh the 

2 indicated security association. 

3 Delete Payload: 

4 The PDSN shall send a delete payload upon a SA refresh or upon request from a service 

5 provider administrator. 
6 
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1 Annex B: Certificates 



2 PDSNs and HAs shall use X.509 Version 3 certificates in conformance with RFC 2459. Each 

3 PDSN and HA in a service provider network may have a unique certificate which will be 

4 configured into the PDSN and HA. The method of configuration of certificates is outside the 

5 scope of this specification. 

6 Note: This Annex only applies to FA CoA. Security between a collocated CoA MS and the HA is 

7 outside the scope of this specification. 

8 Each service provider may be a Certificate Authority for itself and its client private networks and 

9 partner ISPs for PDSNs and for HAs that may be accessed by PDSNs. All PDSNs and HAs shall 

10 be configured with all service provider CA certificates. There should be one CA root certificate 

1 1 from each service provider. 

12 Certificates for PDSNs and HAs: 

13 The Distinguished Name [RFC 2459] contained in the Issuer field is of form: 

14 cdma2000. service-provider-name 

15 The PDSN or HA determines the issuing service-provider (i.e., the CA) from the service-provider- 

16 name attribute of the Issuer's Distinguished Name. The PDSN and HA then use the service- 

17 provider-name attribute to locally access the CA's public key. 

18 The PDSN and HA shall use the SHA-1 as a hash function and either the RSA or DSA signing 

19 algorithm, as specified in RFC 2459 to verify a certificate. The private network or ISP shall 

20 provide the public key and Distinguished Name of the certificate. 

21 The Distinguished Name contained in the Subject field is of form: 

22 cdma2000. service-provider-name. PDSN. service-provider-identifier 

23 cdma2000. service-provider-name. HA.service-provider-identifier 

24 Certificates in the PDSN and HA will not use the Unique-Identifier field. 

25 Certificate extensions for PDSN and HA certificates shall not be supported. 

26 The method of providing PDSNs and HAs signed certificates to PDSNs and HAs is outside the 

27 scope of this specification. 

28 CA Certificates: 

29 Service provider CA certificates shall be configured into all PDSNs and HAs. A service provider 

30 CA contains the public key that the PDSN or HA shall use to verify the signature of a certificate 

31 received in a Phase 1 ISAKMP exchange. 

32 A CA certificate shall conform to the X.509 V3 certificates in RFC 2459. Since the service 

33 provider CA distributes its own certificate, the Authority Key Identifier and Subject Key Identifier 

34 extensions shall not be included in the certificate. 

35 The method by which service providers exchange their CA certificates, as well as of providing 

36 certificates into PDSNs and HAs, is outside the scope of this specification. 

37 Certificate Revocation List (CRL): 

38 CRLs shall be used to store the identities of certificates that have been compromised or are 

39 otherwise invalid. CRLs shall conform to X.509 v2 as specified in RFC 2459. A future version of 

40 this specification may make use of the Online Certificate Status Protocol. 
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1 Service providers shall exchange revoked certificate information (e.g., serial number). The 

2 frequency of the exchange is outside the scope of this specification. 

3 Possession of a certificate does not imply service since the RADIUS server and Mobile IP 

4 functions still control the user obtaining service, as well as the HA allowing access to the PDSN. 

5 The CA certificate shall indicate the service provider CA as Issuer of the CRL. The DN of the 

6 Issuer shall be of form: 

7 cdma2000. service-provider-name 

8 CRLs exchanged between service providers shall use the SHA-1 as a hash function and either 

9 the RSA or the DSA signing algorithm as specified in RFC 2459. 

10 CRL extensions shall not be supported. 

1 1 The method of exchanging CRLs between service providers, or to conveying certificates client 

12 private network or partnering ISP, as well providing this information into PDSNs and HAs, is 

1 3 outside the scope of this specification. 
14 
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1 Annex C: PDSN Timers 



2 The PDSN shall implement a PPP inactivity timer and may implement a PPP session timer and 

3 may implement an accounting interval timer. These timers are defined as follows. 

4 PPP inactivity timer (4-byte unsigned integer): This mandatory timer is configured with the 

5 maximum number of consecutive seconds that a PPP session may be idle. When a PPP session 

6 has been idle for this amount of time, the PPP session may be terminated depending on the 

7 user's Always On status (see 3.2. 1 .7). 

8 PPP session timer (4-byte unsigned integer): This optional timer is configured with the maximum 

9 number of total seconds for which a PPP session may be established. When a PPP session has 

10 been established for this amount of time, the PPP session is terminated, regardless of whether it 

1 1 is active or idle. 

12 Accounting interval timer (4-byte unsigned integer): This optional timer is configured with the 

1 3 number of total seconds between when the PDSN sends periodic interim accounting messages 

14 to the RADIUS server. 

15 The PPP inactivity timer and PPP session timer use the value of 0 to indicate infinity. When 

16 timers are set to an infinity value, they will never expire. 

17 PPP Inactivity Timer 

18 The PPP inactivity timer shall be locally configured on the PDSN with a default value that is used 

19 for all PPP sessions. However, this default value may be overridden on a per session basis with 

20 a RADIUS Idle-Timeout (28) attribute [RFC 2865] that is returned from the RADIUS server in a 

21 RADIUS Access-Accept message. 

22 For Mobile IP service, the PPP inactivity timer shall always be greater than the Mobile IP 

23 registration lifetime. Thus, the PDSN shall always advertise to the MS a maximum allowed Mobile 

24 IP registration lifetime smaller than the PPP inactivity timer value currently in use for the PPP 

25 session. The PDSN shall ignore a non-zero RADIUS Idle-Timeout value received in a RADIUS 

26 Access-Accept message for a Mobile IP session, which is smaller than current PPP inactivity 

27 timer for the PPP session. The PDSN may honor the RADI US-Idle-Timeout value received in a 

28 RADIUS Access-Accept message for a Mobile IP session if the received value is greater than the 

29 one currently in use for the PPP session. 

30 In case of Simple IP service, if the PPP session is marked as "Always-On" then the PDSN shall 

31 perform the link status determination procedure upon expiry of the PPP inactivity timer [see 

32 section 3.2.1.7]. 

33 PPP Session Timer 

34 If the PPP session timer is used, then it shall be locally configured on the PDSN with a default 

35 value that is used for all PPP sessions. However, this default value may be overridden on a per 

36 session basis with a RADIUS Session-Timeout (27) attribute [RFC 2865] that is returned from the 

37 RADIUS server in a RADIUS Access-Accept message. For Always On users, the PDSN shall 

38 discard the PPP session timer. 

39 In the case of multiple MIP sessions over a single PPP session, it is possible that the PDSN 

40 receives different RADIUS-Session-Timeout values from different home networks. In this case, 

41 the PDSN may honor the initial RADIUS-Session-Timeout value that it received and shall ignore 

42 all subsequent RADIUS-Session-Timeout values that it receives. 

43 Accounting Interval Timer 

44 If the accounting interval timer is used, then it shall be locally configured on the PDSN with a 

45 default value that is used for all sessions. However, this default value may be overridden on a per 

46 session basis with a RADIUS Acct-lnterim-lnterval (85) attribute [RFC 2869] that is returned from 
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1 the RADIUS server in a RADIUS Access-Accept message. For a session using the prepaid 

2 service, the RADIUS Acct-lnterim-lnterval shall not be used and the interval timer shall be 

3 interpreted as per X.S001 1-006-C (PrePaid Packet Data Service). 
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